home *** CD-ROM | disk | FTP | other *** search
/ CD Actual 22 / PC Actual CD 22.iso / linux / xfree86 / DOC / README.SVR4 < prev    next >
Encoding:
Text File  |  1998-01-07  |  18.7 KB  |  661 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7.  
  8.  
  9.  
  10.               Information for SVR4 Users
  11.  
  12.                The XFree86 Project, Inc
  13.  
  14.                   1 June 1997
  15.  
  16.  
  17.  
  18.                    Abstract
  19.  
  20.      NOTE: If you intend to use any of the accelerated servers, read sec-
  21.      tion 10 and follow the instructions.  Otherwise the X server will
  22.      crash when exiting, restarting, or switching VTs.
  23.  
  24.  
  25.  
  26. 1.  SVR4 versions on which XFree86 has been tested
  27.  
  28. XFree86 has been tested on the following versions of SVR4.0:
  29.  
  30.    o Microport: 2.2, 3.1, 4.1, 4.2
  31.  
  32.    o Esix: 4.0.3A, 4.0.4, 4.0.4.1
  33.  
  34.    o Dell: 2.1, 2.2, 2.2.1
  35.  
  36.    o UHC: 2.0, 3.6
  37.  
  38.    o Consensys: 1.2
  39.  
  40.    o MST: 4.0.3
  41.  
  42.    o AT&T: 2.1, 4.0
  43.  
  44.    o ISC: 4.0.3
  45.  
  46.    o NCR: MP-RAS
  47.  
  48.    o PANIX: 5.0
  49.  
  50. and the following versions of SVR4.2:
  51.  
  52.    o Consensys
  53.  
  54.    o Novell UnixWare 1.x and 2.0
  55.  
  56. Basically, we believe that XFree86 binaries will run unmodified on any ISA,
  57. EISA, or MCA platform version version of SVR4.0 (Solaris 2.x is an exception),
  58. or SVR4.2.  If you run XFree86 on another version of SVR4 that's not in this
  59. list, please let us know about it.
  60.  
  61.  
  62.  
  63.  
  64. Information for SVR4 Users
  65.  
  66.  
  67.  
  68.  
  69.  
  70. Information for SVR4 Users
  71.  
  72.  
  73.  
  74. 2.  How to cope with VT-switching hotkeys
  75.  
  76. Some versions of SVR4 (Esix and Microport) have mechanisms for enabling two-key
  77. sequences for VT switching (Alt-Fn).  The standard SVR4 mechanism is Alt-Sys-
  78. Req-Fn, which all versions we know use.  Running under X, the Alt-Fn sequences
  79. are stolen by the driver before the server can see them, so you can't use them
  80. for X applications.  So you want to switch back to the standard 3-key sequences
  81. while you are running X.  Here's how to do it:
  82.  
  83.       Microport
  84.         Microport makes this very simple.  The 2-key mode is called "Micro-
  85.         port Mode", and the 3-key mode is called "Compatible Mode".  You
  86.         enter Microport Mode by pressing Alt-SysReq-m.  You enter Compati-
  87.         ble Mode by pressing Alt-SysReq-c.    So all you need to do is press
  88.         Alt-SysReq-c after starting the X server to allow X clients access
  89.         to the Alt-Fn sequences.
  90.  
  91.       Esix
  92.         Esix has no keyboard-driven way to switch modes.  There are two
  93.         levels at which this can be handled:
  94.  
  95.           1.  There is a kernel tunable that determines which mode is the
  96.           default.  The tunable is the initialisation of kd_2keysw in
  97.           /etc/conf/pack.d/kd/space.c.    When set to 1 (the default),
  98.           2-key mode is enabled.  When set to 0 it is disabled.
  99.  
  100.           2.  The mode can be changed for individual VTs programatically by
  101.           an ioctl().  To make life easier for XFree86 users, a program
  102.           called `2key' is provided (in xc/pro-
  103.           grams/Xserver/hw/xfree86/etc/ in the source tree, and in
  104.           /usr/X11R6/lib/X11/etc/ in the binary kit).  You can compile
  105.           and install this program.  Then to make use of it, add the
  106.           line `VTInit "2key off"' to the Keyboard section of your
  107.           XF86Config file to cause the program to be run automatically
  108.           when the server starts up.  Doing this means that 2-key
  109.           switching will be turned off while in the server's VT, but
  110.           will still be on for the other VTs.
  111.  
  112.         For further details, refer to the keyboard(7) man page included
  113.         with the release notes (the on-line man page doesn't have this
  114.         information).
  115.  
  116.  
  117. 3.  Running SVR3 binaries on SVR4.0.4 and SVR4.2
  118.  
  119. SVR4.0.4 added the `Advanced Compatibility Package', which provides iBCS-2 com-
  120. pliance for running SVR3 binaries.  These facilities are also present in
  121. SVR4.2.  XFree86 makes use of this to accept local connections from SVR3
  122. clients.  The XFree86 binary distribution is built to use these capabilities.
  123. You need to install the `Advanced Compatibility Package', if you have not done
  124. so already.
  125.  
  126. We have found that SVR4.0.4 is not able to run all SCO, and perhaps not many
  127. ISC SVR3 binaries.  This is not a failing of XFree86, but of SVR4 itself.  One
  128.  
  129.  
  130.  
  131.  
  132.  
  133.  
  134.  
  135.  
  136. Information for SVR4 Users
  137.  
  138.  
  139.  
  140. particular example is that many SVR3 programs are ignorant of the UFS filesys-
  141. tem, and attempt to read directories as files, rather than using the system
  142. call that is defined for the purpose.  This will fail for obvious reasons.  The
  143. SVR4.0.4 release notes from USL (which you should have gotten from your vendor)
  144. have lots of suggestions for how to improve compatibility.
  145.  
  146. That said, we have had luck with several SCO binaries right out of the box.  No
  147. changes are needed - just go to an xterm window and run the program.
  148.  
  149. ISC users will need a binary editor before they can attempt to run their bina-
  150. ries.  ISC, for whatever reason, put the pipe for local connections in
  151. /tmp/.X11-unix/Xn.  This unfortunately is the same place as the X Consortium X
  152. server puts the Unix-domain socket normally used for local connections.  The
  153. XFree86 server was modified to use /dev/X/ISCCONN/Xn for local connections to
  154. ISC clients.  So what you must do is use a binary editor to edit your client
  155. program.  Search for /tmp/.X11-unix, and change it to /dev/X/ISCCONN.  Now you
  156. just have to worry about base-OS compatibility.
  157.  
  158.  
  159. 4.  Notes for building XFree86 on SVR4
  160.  
  161.   1.  If you are using gcc with SVR4, we highly recommend that you use
  162.       gcc-2.4.5 (or a later stable release).  Version 2.6.0 has some problems
  163.       on i386 platforms and is not recommended.
  164.  
  165.   2.  It is recommended that you increase the UFSNINODE (for a UFS filesystem)
  166.       and/or the S5NINODE (for an S5 filesystem) kernel parameter to about 650
  167.       before attempting to build the distribution.  See the "Notes for running
  168.       XFree86 on SVR4" section for some other parameters you may want to
  169.       change.
  170.  
  171.   3.  The BOOTSTRAPCFLAGS required are:
  172.  
  173.        For Unixware:     "-DUSL"
  174.  
  175.        For NCR:         "-DNCR"
  176.  
  177.        For other SVR4:   "-DSVR4 -Di386"
  178.  
  179.  
  180. 5.  Notes for running XFree86 on SVR4
  181.  
  182. NOTE: If you intend to use any of the accelerated servers, read section 10 and
  183. follow the instructions.  Otherwise the X server will crash when exiting,
  184. restarting, or switching VTs.
  185.  
  186.   1.  For SVR4, you may also need to add /usr/X11R6/lib to your
  187.       LD_LIBRARY_PATH, but this is not required for running properly built
  188.       clients.
  189.  
  190.   2.  You may want to increase some kernel parameters (either by running
  191.       idtune, or editing /etc/conf/cf.d/stune, and rebuilding the kernel with
  192.       idbuild):
  193.  
  194.  
  195.  
  196.  
  197.  
  198.  
  199.  
  200.  
  201.  
  202. Information for SVR4 Users
  203.  
  204.  
  205.  
  206.        [HS]FNOLIM          hard/soft limit for number of open files
  207.  
  208.        MAXUP          max number of processes per user
  209.  
  210.        ARG_MAX          max length of an arg list
  211.  
  212.        SHMMAX          max size of shared memory segment(in bytes)
  213.  
  214.   3.  Choose which mouse driver you will use.  For SVR4 the best choice depends
  215.       on which version you are using.  If you have a bus mouse then Xqueue is
  216.       probably the only option.  For a serial mouse the options are as follows:
  217.  
  218.         Esix 4.0.3
  219.           Xqueue works.  It is also possible to use the standard asy
  220.           driver directly, but the mouse operation is "jerky".
  221.  
  222.         Microport SVR4 [34].1
  223.           Xqueue works fine, and the asy driver can also be used
  224.           directly giving smooth mouse operation.
  225.  
  226.       To use Xqueue, set the Protocol to Xqueue in both the Keyboard and
  227.       Pointer sections of your XF86Config file, and You must have the mouse
  228.       driver package installed, and must run mouseadmin to set it up for your
  229.       mouse.  If mouseadmin won't work try doing `touch /dev/gmse' before run-
  230.       ning it.    (Note that mouseadmin will need to be rerun after rebuilding a
  231.       kernel unless you add an appropriate entry to /etc/conf/node.d/gmse.)
  232.  
  233.       NOTE: Many of the accelerated server/drivers have problems when using a
  234.       HW cursor and Xqueue together.  If you have a serial mouse, you can work
  235.       around this by not using Xqueue.    Otherwise the only workaround is to
  236.       disable the HW cursor.  This is done by adding the line:
  237.  
  238.           Option "sw_cursor"
  239.  
  240.  
  241.       to the Device section of your XF86Config file.  The S3 server is the only
  242.       one known to not have this problem.
  243.  
  244.       If you have problems with both Xqueue and your standard asy driver with
  245.       SVR4, then you should install SAS.  When using SAS, set up XF86Config as
  246.       you would for the standard driver.
  247.  
  248.       SAS is available from ftp.physics.su.oz.au.  When using SAS for a serial
  249.       mouse, you will get smoother operation if you change EVENT_TIME from 80
  250.       to 30 in sas.h.  A couple of details which aren't spelled out in the SAS
  251.       README are:
  252.  
  253.       - An example of the line you should add to /etc/ap/chan.ap is:
  254.  
  255.          MAJOR      0      255      ldterm ttcompat
  256.  
  257.  
  258.       where MAJOR is replaced by the major number used for SAS devices.  To
  259.       determine what that is, check /etc/conf/cf.d/mdevice after rebuilding the
  260.  
  261.  
  262.  
  263.  
  264.  
  265.  
  266.  
  267.  
  268. Information for SVR4 Users
  269.  
  270.  
  271.  
  272.       kernel.  The major number is the sixth field in the line starting with
  273.       `sas'.  This file must be updated before rebooting with the new kernel.
  274.  
  275.       - The installation instructions omit the following:
  276.  
  277.        3a) Disable the asy driver by either running `kconfig' or edit-
  278.        ing /etc/conf/sdevice.d/asy.
  279.  
  280.        3b) Rebuild the kernel by running /etc/conf/bin/idbuild
  281.  
  282.   4.  If you want to use xdm with SVR4, extract the files from the shar file in
  283.       /usr/X11R6/lib/X11/etc/XdmConf.svr4 into a temporary directory.  The
  284.       README file tells where the individual files should be installed.  Be
  285.       sure to read through each file and make any site-specific changes that
  286.       you need.
  287.  
  288.       NOTE: Some SVR4 versions (one example is Esix 4.0.3) have a default init-
  289.       tab which runs `vtgetty' on the console. This does not work well when
  290.       starting xdm at boot time.  The problem is that when you logout from a
  291.       vtgetty session it wants to close all the VTs -- including the one xdm is
  292.       using for the server.  It is recommended that you use `getty'.  If you
  293.       change /etc/inittab, remember to also change /etc/conf/cf.d/init.base or
  294.       you will lose the changes when you next rebuild the kernel.
  295.  
  296.   5.  If you want to change the number of VTs available on SVR4, just edit the
  297.       file /etc/default/workstations and change the number there.  The device
  298.       nodes will be created/deleted next time you reboot.
  299.  
  300.   6.  The default local connection types have changed in X11R6.  Unix domain
  301.       sockets are no longer treated as a "local" connection type.  This means
  302.       that a client connecting to :0 will use not use a Unix socket for the
  303.       connection.  To use the Unix socket connection, the client must connect
  304.       to unix:0.
  305.  
  306.       The local connection types available are "NAMED" (named streams pipe),
  307.       "PTS" (old-stype USL streams pipe), "SCO" (SCO Xsight streams pipe), and
  308.       "ISC" (ISC streams pipe).  The XLOCAL environment variable can be used to
  309.       set which types of local connection should be used in order of prefer-
  310.       ence.  The default setting is PTS:NAMED:ISC:SCO.    It is recommended that
  311.       NAMED be used in most cases because it is faster than the default PTS,
  312.       and because using PTS can cause you to run out of /dev/pts/ devices (each
  313.       client using PTS requires a /dev/pts device).  To set up the default
  314.       local connection type, make sure that XLOCAL is set and exported in your
  315.       .xinitrc file (when using xinit or startx) or your
  316.       /usr/X11R6/lib/xdm/Xsession script (when using xdm).
  317.  
  318.  
  319. 6.  Building non-core clients with SVR4
  320.  
  321.   1.  A lot of clients (even some which have explicit SVR4 support) require
  322.       -DSYSV when building under SVR4.    This will not be set when using the
  323.       default configuration.  A quick fix is to add something like the follow-
  324.       ing to the client's Imakefile:
  325.  
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334. Information for SVR4 Users
  335.  
  336.  
  337.  
  338.          #if SystemV4
  339.               DEFINES = -DSYSV OTHER_CLIENT_DEPENDENT_DEFINES
  340.          #endif
  341.  
  342.  
  343.       The best solution is to modify the code so it compiles correctly without
  344.       -DSYSV.
  345.  
  346.  
  347. 7.  Using DOS/Merge 2.2 with XFree86
  348.  
  349. It is possible to use the Locus DOS/Merge 2.2 X clients with XFree86.  You need
  350. to do a couple of things for this to work, though.  One change is a generic
  351. problem with the X client and X11R5/6; the others are to work with some things
  352. that are specific to the XFree86 servers.  Here are the things you need to do:
  353.  
  354.   1.  Set and export $XMERGE in your .xinitrc and/or .xsession files.  In gen-
  355.       eral, you should set XMERGE=vga.
  356.  
  357.   2.  You MUST use the "xqueue" driver instead of the server's native keyboard
  358.       and mouse driver, if you intend to use the "zoom" feature of the `dos'
  359.       client.  Otherwise the mouse will cease to function after the first time
  360.       you "zoom" (because the `dos' client uses the native driver, and the
  361.       server will not be able to access the mouse after the zoom ends).  The
  362.       only other alternative is to use separate mice on separate devices.
  363.  
  364.   3.  You need to install the `dos' client fonts in the XFree86 font directo-
  365.       ries.  Locate the BDF files (search for files with names matching the
  366.       pattern `*pc???.bdf').  These will likely be /usr/lib/X11/fonts/misc.  Go
  367.       to the directory where these files are located, and execute the following
  368.       (using `sh' or `ksh'):
  369.  
  370.         for i in *pc???.bdf
  371.         do
  372.             /usr/X11R6/bin/bdftopcf $i > \
  373.               /usr/X11R6/lib/X11/fonts/misc/`basename $i .bdf`.pcf
  374.         done
  375.         cd /usr/X11R6/lib/X11/fonts/misc
  376.         /usr/X11R6/bin/mkfontdir
  377.         # Do this only if the server is already running.
  378.         /usr/X11R6/bin/xset fp rehash
  379.  
  380.   4.  The `dos' client program uses a translation table to map from an internal
  381.       key representation to the X keymap.  It is likely that the table supplied
  382.       with Merge 2.2 use the mapping for SCO's server.    A correct mapping table
  383.       is available in /usr/X11R6/lib/X11/etc/xcode.xfree86.  This file should
  384.       be installed in /usr/lib/merge/xc.  In addition, you must add the follow-
  385.       ing resource to the `dos' client's application-defaults file (usually in
  386.       /usr/lib/X11/app-defaults/DOS):
  387.  
  388.         dos*xcodetable: /usr/lib/merge/xc/xcode.xfree86
  389.  
  390.  
  391.       It will be obvious if this new code table is needed, as the arrow keys on
  392.  
  393.  
  394.  
  395.  
  396.  
  397.  
  398.  
  399.  
  400. Information for SVR4 Users
  401.  
  402.  
  403.  
  404.       the keypad will fail to function in the `dos' client if the wrong table
  405.       is installed.
  406.  
  407.   5.  For the "zoom" feature to work correctly, you must run `dos' with $DIS-
  408.       PLAY set to "unix:N" or "host_name:N".  If you use just ":0", the client
  409.       will not function properly.  `dos' does not accept a `-display' parame-
  410.       ter.  Hence it is probably a good idea to replace the `dos' program with
  411.       something like this:
  412.  
  413.         #!/usr/bin/ksh
  414.         if [ "X${DISPLAY}" != "X" ]
  415.         then
  416.              case ${DISPLAY} in
  417.              :*)
  418.               DISPLAY=unix${DISPLAY}
  419.               ;;
  420.              esac
  421.         fi
  422.         /usr/bin/dos.real "$@"
  423.  
  424.  
  425. 8.  Keyboard mapping problems with some Esix systems
  426.  
  427. One of the console driver patches for Esix 4.0.3A causes the XFree86 server's
  428. default keymap to be corrupted.  If you are being affected by this problem it
  429. will be obvious because few (if any) of the keys will be mapped correctly.
  430. There are two solutions to this.  One is to remove the console driver patch
  431. which introduced the problem.  The second is to use xmodmap(1) to reset the
  432. default mapping after server startup.  The default mapping is provided in the
  433. file /usr/X11R6/lib/X11/etc/xmodmap.std, and can be installed automatically by
  434. adding the line:
  435.  
  436.        xmodmap /usr/X11R6/lib/X11/etc/xmodmap.std
  437.  
  438.  
  439. to your .xinitrc file (or your Xsetup file if using xdm).
  440.  
  441.  
  442. 9.  106 Japanese keyboard problem on PANIX
  443.  
  444. PANIX for PC-AT uses Japanese keycodes standardized by DICOP(Desktop UNIX for
  445. Intel Cooperative Promotion Group) in Japan.  Therefore keycode confliction
  446. occurs with 106 Japanese keyboard in XFree86.  To avoid it, specify the keyword
  447. "panix106" in XF86Config like this:
  448.  
  449.        Section "Keyboard"
  450.      Protocol    "Standard"
  451.      Autorepeat  500 5
  452.      XkbModel    "jp106"
  453.      XkbLayout   "jp"
  454.      panix106
  455.        EndSection
  456.  
  457.  
  458.  
  459.  
  460.  
  461.  
  462.  
  463.  
  464.  
  465.  
  466. Information for SVR4 Users
  467.  
  468.  
  469.  
  470. 10.  A kernel patch that is required for accelerated servers
  471.  
  472. SVR4.0 has a bug handling programs that access extended I/O registers (above
  473. 0x3FF).  Boards like S3 and 8514/A use these extended I/O registers.  XFree86
  474. supports boards that tickle this bug.  In preparation for using these servers,
  475. we have produced a kernel patch that works around the problem, and provided
  476. scripts for you that will both install and back out the patch.    You must
  477. install this if you intend to use the S3, 8514, Mach8, Mach32, P9000, AGX or
  478. W32 servers.
  479.  
  480. Dell 2.2 is known to not need the patch, because Thomas Roell found and fixed
  481. the bug while he was working for Dell.    Microport has fixed this in their 4.0
  482. v4.2 release.  Also, SVR4.2 does not need this patch, as the problem has been
  483. fixed by USL.
  484.  
  485. The patch scripts are located in xc/programs/Xserver/hw/xfree86/etc in the
  486. source tree, and /usr/X11R6/lib/X11/etc in the binary distribution.  The files
  487. are `svr4_patch' to install the patch, and `svr4_patch_rem' to back it out.
  488. The file that is being patched is /etc/conf/pack.d/kernel/os.o.  The patch
  489. script verifies the presence of the bug before patching, and will tell you
  490. whether or not it succeeded in patching.  You need to run the `svr4_patch'
  491. script as root, obviously.  The original os.o file, as well as the patching
  492. program, and a copy of the removal script are stored in the directory
  493. /etc/conf/pack.d/kernel/.xfree86
  494.  
  495. Thanks to John M. Sully of Microport for helping us find a simple workaround
  496. for this problem, and giving us permission to release the information.
  497.  
  498.  
  499. 11.  Other problems
  500.  
  501. Some accelerated drivers may cause the machine to lockup when starting up the
  502. server on some versions of SVR4.0.  The problem seems to be related to the ker-
  503. nel checking for the presence of physical memory when mmaping /dev/pmem.  This
  504. can cause problems when mapping memory mapped registers.  This is known to be a
  505. problem with the MGA driver in the SVGA server.  Some other drivers may be
  506. affected too.  We currently have no workaround for this.
  507.  
  508.      Generated from XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/SVR4.sgml,v 3.13.2.1 1997/06/01 12:33:36 dawes Exp $
  509.  
  510.  
  511.  
  512.  
  513.  
  514.      $XConsortium: SVR4.sgml /main/8 1996/10/27 11:06:06 kaleb $
  515.  
  516.  
  517.  
  518.  
  519.  
  520.  
  521.  
  522.  
  523.  
  524.  
  525.  
  526.  
  527.  
  528.  
  529.  
  530.  
  531.  
  532. Information for SVR4 Users
  533.  
  534.  
  535.  
  536.  
  537.  
  538.  
  539.  
  540.  
  541.  
  542.  
  543.  
  544.  
  545.  
  546.  
  547.  
  548.  
  549.  
  550.  
  551.  
  552.  
  553.  
  554.  
  555.  
  556.  
  557.  
  558.  
  559.  
  560.  
  561.  
  562.  
  563.  
  564.  
  565.  
  566.  
  567.  
  568.  
  569.  
  570.  
  571.  
  572.  
  573.  
  574.  
  575.  
  576.  
  577.  
  578.  
  579.  
  580.  
  581.  
  582.  
  583.  
  584.  
  585.  
  586.  
  587.  
  588.  
  589.  
  590.  
  591.  
  592.  
  593.  
  594.  
  595.  
  596.  
  597.  
  598.  
  599.  
  600.  
  601.  
  602.                    CONTENTS
  603.  
  604.  
  605.  
  606. 1.  SVR4 versions on which XFree86 has been tested .......................... 1
  607.  
  608. 2.  How to cope with VT-switching hotkeys ................................... 2
  609.  
  610. 3.  Running SVR3 binaries on SVR4.0.4 and SVR4.2 ............................ 2
  611.  
  612. 4.  Notes for building XFree86 on SVR4 ...................................... 3
  613.  
  614. 5.  Notes for running XFree86 on SVR4 ....................................... 3
  615.  
  616. 6.  Building non-core clients with SVR4 ..................................... 5
  617.  
  618. 7.  Using DOS/Merge 2.2 with XFree86 ........................................ 6
  619.  
  620. 8.  Keyboard mapping problems with some Esix systems ........................ 7
  621.  
  622. 9.  106 Japanese keyboard problem on PANIX .................................. 7
  623.  
  624. 10. A kernel patch that is required for accelerated servers ................. 8
  625.  
  626. 11. Other problems .......................................................... 8
  627.  
  628.  
  629.  
  630.  
  631.  
  632.  
  633.  
  634.  
  635.  
  636.  
  637.  
  638.  
  639.  
  640.  
  641.  
  642.  
  643.  
  644.  
  645.  
  646.  
  647.  
  648.  
  649.  
  650.  
  651.  
  652.  
  653.  
  654.  
  655.  
  656.  
  657.  
  658.                        i
  659.  
  660.  
  661.